テスト環境でCanvas APIが使えない

🎨 Canvas API制約の問題

「テスト環境でのCanvas API制約により実際の圧縮処理は困難」とは：

Node.js環境にはネイティブCanvas実装がない

happy-dom/jsdomはCanvas APIの完全な実装を提供しない

実際の画像処理（描画・圧縮）はブラウザ環境でのみ可能

そのため、現実的なテスト戦略として：

1. ユニット: モックで論理をテスト

2. 統合: APIレベルでテスト

3. E2E: 実ブラウザで完全フローをテスト

この分離により、テスト環境の制約を回避しつつ、品質を担保しています。

1. テスト環境での制限

テスト環境（Vitest + happy-dom/jsdom）では：

Canvas要素は存在するがgetContext()が null を返す

toBlob()メソッドが機能しない

実際の画像描画・圧縮処理ができない

2. ブラウザ vs テスト環境の違い

table:_

機能 ブラウザ環境 テスト環境

Canvas作成 ✅ 動作 ⚠️ 要素のみ作成

getContext('2d') ✅ Context取得 ❌ null返却

drawImage() ✅ 画像描画 ❌ 実行不可

toBlob() ✅ 圧縮実行 ❌ コールバック呼ばれない

3. 実際の障害

code:ts

// ExtremeCompression.test.ts での実際のエラー

describe('Extreme Compression Integration Tests (ADR-017)', () => {

it('should compress 10MB image to under 1MB', async () => {

const result = await compressImage(tenMBFile); // ❌ Canvas contextエラー

});

});

4. 対処方針

✅ 現在の解決策

code:zsh

// 制約の大きいテストをスキップ

describe.skip('Extreme Compression Integration Tests', () => {

// テスト環境でのCanvas API制約により実際の圧縮処理は困難

// 本テストは手動ブラウザ環境での品質検証用として保持

});

✅ 代替テスト戦略

1. モックベーステスト - 単体テスト（Small）で論理フローをテスト

2. 統合APIテスト - サーバーサイドの画像処理をテスト

3. E2Eテスト - 実ブラウザでの完全フロー検証

5. 品質保証の手法

code:zsh

// ✅ 実用的なアプローチ

// Small: ロジックテスト（Canvas API制約を避けてモック）

it('should handle AVIF fallback to WebP', () => {

// モックでCanvas APIの振る舞いをシミュレート

});

// Medium: 統合テスト（実際のAPIエンドポイント）

it('should upload compressed image via integrated API', () => {

// 実際のアップロードAPIをテスト

});

// E2E: ブラウザテスト（実際のCanvas API使用）

test('should compress and upload image in real browser', () => {

// Playwrightで実ブラウザ環境でテスト

});